Summary

Follow-up to #26. Hooks RadialProgress into the hasShaderTimeFn machinery so the shader can drive its own animation without a JS-side tween.

• New props: duration (ms per cycle, 0 = disabled) and countdown (0 = fill 0→1, 1 = drain 1→0).
• When duration > 0: WebGL derives progress from u_time in GLSL; Canvas2D derives it from node.time in render(). time: true on both backends so the stage marks the node as timed and u_time is plumbed automatically.
• When duration === 0 (default): the existing static progress prop is used — non-animated and JS-animated callers are unchanged.

Why

A countdown ring updating from a JS animation tween costs a CPU-side prop write and a per-frame uniform repush. With duration/countdown, the only per-frame work is requestRender() + one fragment-shader `fract()` — significantly cheaper for the common "always-on circular timer" UI.

API delta

```ts
// before (still works):
node.animate({ shaderProps: { progress: 0 } }, { duration: 2000, loop: true }).start();

// after — equivalent, no JS animation needed:
renderer.createShader('RadialProgress', {
duration: 2000,
countdown: 1, // 1 = drain (countdown), 0 = fill
// ...
});
```

Test plan

• `pnpm build` clean
• `pnpm exec vitest run` — 190/190 (4 new for duration resolver + a default-shape check)
• Visual sanity in `pnpm start`: fill ring and countdown ring both animate smoothly under WebGL.
• Canvas2D path verified with `?renderMode=canvas`
• `pnpm start:prod` to confirm transpile-floor compatibility

🤖 Generated with Claude Code